(PART 2) Renames old livekit-uniffi builds to use ffi instead post livekit-ffi / livekit-uniffi merge - #1439

…fi` with `room-apis` and`core-modules` modes (#1438)

## Background
Ever since we [introduced
livekit-uniffi](#750) at the
start of 2026, it has been getting increasingly confusing what the
difference between `livekit-ffi` (existing C ABI ffi solution used by
python, node, unity, and c++ sdks that exposes a full rust owned webrtc
stack) and `livekit-uniffi` (new uniffi powered ffi solution used by
swift, android, and flutter that exposes utility modules) actually are
to those that haven't been intimately involved with the rust adoption
initiative.

This has become even more confusing now that we have recently [added
uniffi to the livekit-ffi
crate](#1308)... 😬

The original intention was that `livekit-uniffi` would be a somewhat
transitional "playground" we could use to experiment with uniffi and
make sure we were ready to commit to it before moving everything
wholesale over to it. We're now at the point where we're ready to commit
to it, so this change aims to consolidate all FFI usage (both C ABI FFI
and uniffi flavors) into one monolithic `livekit-ffi` crate again.

## Overview 

Moves all code from `livekit-uniffi` into `livekit-ffi` and **outright
removes** the `livekit-uniffi` crate. This implements "phase 3" of the C
ABI -> uniffi migration plan document discussed last month.

`livekit-ffi` now has two top level "modes" controlled by features:
- The `room-apis` mode is exactly what `livekit-ffi` used to be - the C
ABI ffi stack using the `livekit` crate that manages a full webrtc
stack. This build is still built in ci exactly as it was before, and
consumed by python/node/unity/c++.
- The `core-modules` mode ie exactly what `livekit-uniffi` used to be -
the newer uniffi exposed set of utilities which are consumed by the
swift, android, and flutter sdks.

## Common functionality
As we migrate the `room-apis` mode to fully use uniffi, there will
inevitably be bits and pieces we want to expose to both "modes". This
pull request surfaced one initial candidate - the `build_version`
function. This was exposed identically in both old uniffi
implementations so now this is defined once and not gated by either
"mode".

## Backwards compatibility
This pull request _should_ be fully backwards compatible. That means in
practice that "core modules" builds will still include identifiers
within that mention `uniffi` - ie, `LiveKitUniFFI` in swift, etc. I've
broken out a second step to this process in #1439 which actually cuts
over the names to the new `ffi` naming, but as this is a breaking change
we'll need to ensure that all downstream sdks do this update in lock
step.

We can also choose to not merge this second step if it is going to be
too disruptive and the resulting naming debt is deemed acceptable.

## TODO
- [x] Fix the dual versions of prost (`prost` vs `prost_012`) which seem
to have made their way in because `livekit-ffi` and `livekit-uniffi` had
different versions in use. Standardize on whatever the repo uses
generally.
  - This has been done and broken out into a separate PR (#1447)
- [x] Rebase on top of `main` once
#1447 merged.

The Rust core package moved to the `livekit-ffi` crate
(livekit/rust-sdks#1438, livekit/rust-sdks#1439) and is now published on
pub.dev as `livekit_ffi`. This swaps the dependency from
`livekit_uniffi: ^0.2.2` to `livekit_ffi: ^0.13.1`.

Five commits:

1. **Replace livekit_uniffi with livekit_ffi ^0.13.0**: pubspec,
lockfile, the import in the native facade, and the crate/release/path
names in `AGENTS.md`. The local override path is now
`../rust-sdks/livekit-ffi/packages/dart`. The pending
`uniffi-rust-core-dev-wiring` changeset is reworded instead of adding a
new one, since #1160 has not shipped yet.
2. **Rename the uniffi facade files to ffi**: `lib/src/uniffi/` becomes
`lib/src/ffi/` and `test/uniffi/` becomes `test/ffi/`. Pure rename plus
reference updates.
3. **Rename LiveKitUniffi to LiveKitFfi**: the facade class is still
unreleased, so it follows the package name now rather than after it
ships.
4. **Rename LiveKitFfi to LiveKitFFI**: follows the all-caps acronym
style of the existing public API (`E2EEManager`,
`LiveKitE2EEException`).
5. **Bump livekit_ffi to ^0.13.1**: picks up the latest release.

## Testing

- `livekit_ffi` 0.13.1 is on pub.dev under the livekit.io publisher, and
the `livekit-ffi/v0.13.1` release carries all 12 `build-<triple>.zip`
assets with sha256 sidecars.
- `flutter analyze`: no issues.
- `flutter test`: 457 pass, including `test/ffi` against the
hook-downloaded library.
- `flutter build macos --release` of the example:
`livekit_ffi.framework` is a fat binary (x86_64 + arm64).

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>